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Abstract 

We present a generator of behavioural component models 
which is highly flexible as it neither depends on a particu- 
lar modelling technique, nor on a specific input format of 
a component specification. It is currently tuned for VHDL, 
but in fact is not HDL specific. To obtain a maximum 
degree of flexibility, the generator was designed as a 
model development environment basically composed of 
four module types; preprocessor modules parsing and 
processing component specifications of a specific defini- 
tion format, method modules representing the component 
modelling technique to be used, a server module that con- 
trols and invokes various generation activities, and finally 
a client module constituting the user interface. To provide 
a model developer with a workbench that can be tailored 
to his individual needs and grow with his experience is the 
major concern of our wort 

1. Introduction 

Development of reliable models of hardware components 
becomes an element of production of electronic equip- 
ment For those developing models for industry, standards 
for component model definition [Coe90. EIA, VTTAL92] 
and computer support in a process of models* development 
have become an indispensable need. Tools, and especially 
model generators provide the only reasonable chance to 
apply appropriate modelling methods in such a huge engi- 
neering effort as development of model libraries is. 
Literature on VHDL model generation does not provide 
many examples of operational systems. The best known 
are Gajski's SpecCharts and Modeller's Assistant [Sin90]. 
However these two are most predominantly concerned 
with a specification language used, SpecCharts and Proc- 
ess Model Graph respectively. Our goals are closer to 
those of the MODES modelling expert system 
[MODES91]. We have however concentrated on develop- 
ment of a workbench integrating different modelling rules 
including modelling conventions [EIA], which enables 
realization of our main goals, namely investigations on the 
compatibility of generated models, model generation tech- 
niques, and on die simulation efficiency of the generated 
VHDL code. - 
The workbench should support 

• An extendable set of component modelling tech- 
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• An extendable set of component specification for- 

•• \,,, -mats . '• •.' V:i ' : v j ir- 

• Sharing of component specifications by different 
modelling techniques ~ 

• Generation of complete component models in con- 
trast to partial models which have to be manually 

extended'"'" 1 " jV " ' 

• A powerful programming environment in order to 
ease maintenance — " : * 

In this paper we describe the architecture of the work- 
bench and its basic concepts, mainly the idea of an inter- 
mediate component representation and additional method 
specific information. We give an example to illustrate the 
information flow from a datasheet to the corresponding 
component model in VHDL. - 

2. Conceptual Background 

Intermediate component specification language 

Basically, a generator for component models is nothing 
but a compiler transforming instances spec of a source lan- 
guage SPEC into corresponding instances hdl of a target 
language HDL. Generators of this type are commonly used 
to support specific modelling techniques, seeing that com- 
ponent specifications usually depend on the technique 
being used. When different modelling techniques are used 
at the same time, the use of many generators and sets of 
component specifications for each of them is inadequate 
due to die enormous effort needed for this work. Therefore 
we use a uniform specification language as an intermedi- 
ate format which is used by all generators. This means that 
each component needs to be specified only once but may 
be used to generate different component models cone- 
sponding to the different modelling techniques. 

Modelling method specific information 

It immediately turns out that, due to differences between 
modelling techniques, the use of a single specification lan- 
guage is not feasible in practice. Modelling techniques 
though conceptually similar in many cases, usually show 
differences that makes generation of all the details of the 
respective component models impossible. If one would try 
to develop a specification language that is powerful 
enough to handle all the information possibly needed, me 
complexity of hardware description languages would eas- 
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ily be reached. To avoid that, we decided to split all com- 
ponent specifications into two parts. One part is an 
instance of the so called abstract component model. 
(ACM), a specification language that was designed to 
specify basic information commonly needed by modelling 
methods. The other part, called method specific informa- 
tion (MSI), is used to specify information that is not cov- 
ered by the ACM but needed for model generation- 
Preprocessors for different specification languages 

Another important feature of our workbench is the concept 
of preprocessor module (PM) which allows a model devel- 
oper to use different specification languages to create 
instances of the ACM. This concept is of relevance, as 
libraries of components may generaly be split into classes 
of component types with similar attributes. In order to 
simplify component specification, it is often feasible to 
define class-specific definition formats. Specifications 
written in those formats are transformed by respective pre- 
processor modules into a corresponding instance of the 
ACM. The existence of different definition formats is 
completely transparent for the modules which transform 
instances of the ACM into component models, as they 
only access the ACM but not the original specification. 
Figure 1 schematically shows the overall generation proc- 
ess. 
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Figure 1 : Flow of Information from 

specification to component model 

3, Abstract Component Model 

This chapter describes the ACM more in detail, as this is 
the primary concept the whole system is based on. It must 
clearly stated that it is not directly available : it is an object 
that is accessed via a functional interface whenever a piece 
of information is requested. The example given in this arti- 



cle only represents instances of a particular specification 
language strongly related to the ACM. 

. '\ - ACM Concept y;\ ;V: 

The main goal was to define an intermediate form for 
component representation with restricted functionality, 
which has both the expressiveness needed to model a com- 
prehensive set of hardware components and the simplicity 
that allows its easy transformation in a HDL (not necessar- 
ily VHDL) representation according to a modelling tech- 
nique. It is based on concepts which are found in common 
HDLs like VHDL, namely: concurrent processes with an 
internal state, shared signals used to communicate 
between processes, guarded commands that realize state 
changes and assertions that check correct component 
usage. Normally, most of the information needed to gener- 
ate a component model is contained in the ACM, only 
minor additions are given via the MSI. Thus, it may be 
seen as the language which defines the set of components 
that is processable by our workbench. 

Components and processes 

We represent hardware as a set of concurrently operating 
indivisible units called processes that communicate via 
shared signals. We use a concept of module (called com- 
ponent) representing a subset of processes. This subset 
will be transformed by a so called method module to a 
component model using the module concept of the respec- 
tive target HDL (e.g. the entity concept in VHDL). That is 
exactly what each instance of the ACM represents, namely 
an independent component consisting of an arbitrary 
number of processes. Each process performs a set of oper- 
ations depending only on its current state and the current 
values of its input signals. We call these operations 
guarded commands, as their execution is triggered by 
boolean expressions. 

Process transitions via guarded commands - 

It is assumed that hardware units perform only a limited 
set of operations. These operations are represented by an 
ordered collection of guarded commands that each process 
contains. The guard is the condition under which a corre- 
sponding set of operations is performed. Guarded com- 
mands are atomic in the sense that when they are 
performed all commands are executed without interrup- 
tion by commands of other processes. 

Limited set of commands and expressions 

We allow only a limited set of commands that we assume 
to be powerful enough to model almost all components, in 
order to ease their transformation into a HDL. We restrict 
ourselves to the following features: ^ 

• conditional execution (if, then, else) 

• fixed signal and variable types (boolean, bit, inte- 
ger, real) 

• delayed signal assignment 

• check for signal change in expressions (only rising, 

• basic type conversion functions (e.g. integer value 
to list of bit values) . 

but particularly omit the following features, as their intro- 
duction would inhibit the use of a wider set of modelling 
techniques: 
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» repetitive execution (loops, while,...) 

• user defined types (such as array, record) 

• • complex signal attributes (like stable in VHDL) 

• VHDL code 

We therefore have an intermediate specification format, 
that is not restricted to be transformed into VHDL, but 
may also be used with other HDLs even with conventional 
programming languages like C. 

Signals, ports, value system 

Basically, process communication is realized via signals 
that are shared between processes. In order to build mod- 
ules of hardware that correspond to reusable component 
models, the concept of port is introduced. A port is noth- 
ing but a public signal with an assigned mode, either in, 
out or inout (lines 9 to 11 in § 5.2 Example 1). Each port 
may be used just like a private signal with the restrictions 
imposed by the mode. In order to support tristate and open 
collector logic, we introduced a value/strength system, 
associated with die type bit which allows for definition of 
signals that may be written by more than one process (like 
a resolved type in VHDL): 

• F0,F1,FX (forced low, high, undef) 

• W0,W1,WX (weak low, high, undeO 

• Z (high impedance) 

The values of all sources (one for each writing processes) 
are mapped (like using a VHDL resolution function) to 
one of the following values: *0* (low), *1 ' (high), 'X' 
(undefined). 

Delayed signal assignment, delay time declara- 
tions, operating conditions 

In order to model timing behaviour, the ACM supports the 
use of a delayed signal assignment statement that refer- 
ences die declaration of a specific delay rime. Delay time 
declarations allow sharing of identical delay times. They 
consist of a propagation delay and a load dependent delay 
part for each of the component's operating conditions 
(min, typ, max). They allow dividing of delay times within 
the ACM, and mapping to a single piece of source code 
within a generated component model. Operating condi- 
tions are used to support a concept which is found in many 
modelling techniques. The different operating conditions 
of a component do not need to be modelled explicitly, a 
single delayed signal assignment is sufficient 

Assertions 

In addition to the component's pure functionality, restric- 
tions on its use must usually be specified. The ACM 
allows for specification of following constraint types: 
setup violation, hold violation, check of pulse width and 
undefined signal. Again we use constraint time declara- 
tions to allow sharing of specific time values. 

4. Architecture of the workbench 

4.1 Implementation issues 

We have chosen Prolog as the main implementation lan- 
guage for the workbench and Smalltalk to implement the 
user interface. Prolog's features backtracking and unifica- 
tion are very effectively usable in the traversal or transfor- 
mation of complex data structures. Smalltalk is a highly 



interpretative (program changes allowed during runtime) 
object-oriented language. Usually implementations are 
complete development^nvironrncnts with a comprehen- 
sive set of predefined classes. It allows the development 
and maintenance of complex interactive user interfaces 
with only little effort. 

Hie generator implemented in Qulntus-Prolog acts like a 
server, whereas the user interface implemented in Object- 
works-Smalltalk (the client) manages the design informa- 
" tion and completely controls the workbench. The system 
runs on a Unix-workstation and should be easily portable 
on any platform that runs the systems noted above. 

4 J, Data model 

We decided to leave management of objects which have to 
be stored permanently (e.g. component specifications) to a 
client application, as the generator itself should only pro- 
vide basic services. Moreover, comfortable applications 
should be supplied by a user interface implemented in a 
language that is well suited to map interface concepts to 
concepts supplied by the generator. We introduced folders 
and categories to group component specifications as well 
as component models, both concepts that arc unknown 
within the generator. Currently there are three user defina- 
ble entities, shortly presented below. 

Component specification 

It represents the specification of a hardware component It 
includes the name of a definition type that stands for a pre- 
processor module and the source code being transformed 
by the preprocessor module into the ACM. In fact, mere 
should be exactly one such component specification for 
each datasheet of a component catalogue. Each component 
specification may be used by several component models. 

Component model 

Represents one specific component model. Any informa- 
tion that is used during source code generation of this 
component model is specified in this instance. It includes 
source code representing the MSI, a reference to the com- 
. ponent specification and a reference to one of the configu- 
rations of the method module that is used to generate die 
HDL source code. 

Method configuration 

Method configurations represent variations of modelling 
techniques. Instead of denning one specific method mod- 
ule for each of these variations we specify those options as 
a piece of source code. Method configurations are owned 
by a method, as they are processed by the respective 
method module, syntax may therefore depend on the 
method they are owned by. 

43 Modules 

Each module represents a collection of Prolog source files, 
they are grouped by functionality. In case of multiple 
instances (e.g. preprocessor modules) only one at a time is 
active. .■ >•-.- ,;/r 

Client module ' ^ ""' - - 

Modules of this type are no element of the generator itself, 
they instead represent applications that access the genera- 
tor resources. An example is a network-module that offers 
functionalities to the server via a communication mecha- 
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Figure 2: Control and dataflow in the workbench 



nism of the operating system. In our case this interface is 
used by a browser implemented in Objectworks-Smalltalk. 

Server module 

This module coordinates the invocation of functions 
within the other modules and guarantees die predefined 
protocol It furthermore maps higher level function calls 
into lower level calls and simplifies the implementation of 
services within the preprocessor modules. 

Preprocessor modules 

Those modules represent the specification types that are 
referenced by component specifications. Before a compo- 
nent model could be generated, the preprocessor module 
of the referenced component specification has to be con- 
sulted so that die component specification can be proc- 
essed by mat module. Each preprocessor module has to 
supply a functional interface (a set of predicates) that is 
used to access the ACM. 

Method modules 
These modules represent modelling techniques. Before a 
component model referencing a specific method configu- 
ration could be generated, the corresponding method mod- 
ule has to be consulted. Method modules transform a 
component specification given as the ACM and MSI into 
the corresponding model in a HDL. 



5. 
5.1 



Example 



Datasheet of Standard Cell Library 
Item [Sie89] 

Figure 3 constitutes a part of a datasheet of a standard cell 
catalogue. It illustrates the way functionality and timing 
are given at this abstraction level. This datasheet corre- 
sponds to the component specification given in § 5.2 
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Figure 3: Datasheet of 4-bit counter 



5.2 Component specification 

The following code shows the specification of a counter. 
This specification format was specially designed to mirror 
directly the concepts of the ACM. Prolog-like syntax is 
used in order to simplify parsing (done by the correspond- 
ing preprocessor module). 

Lines 8 to 30 define a process; three guarded commands 
(beginning with 4 when') are shown. The guarded com- 
mand in line 22 to 29 is transformed to the VHDL source- 
code shown in Example 3 from line 25 to 41. In line 23 
(Example 1) a macro, defined in lines 37 to 39, is called 
(macros are a feature of the preprocessor, not of the 
ACM). This illustrates one possibility of metaprogram- 
ming which may easily be used with Prolog. '■' 



1 .component , CUD42 , ..i 

2 name ■ :--U>C0D4a , *: iJ ^r*- iS - r ^- v'^- * t-- . 

3 , , ; , coaaent :a '4 -bit UP/DOWN -COUNTER with 

CLEAR/ EXPANDABLE' . ; i /; y /l^, 

4 " *v:port(cd) modus in r type ctl rename 'CD', 

;. i ^i?-^ comment'' clear* V*!"*-*^: ^U-r^K ■ 
5 : port < qa ) : - raodus out ,, type bit, name 'QA* > ; 

, comment 'counter bit l„'-.y.-. : . ... .. . 

6 ^ y* 1 other ports analogous */ "' " - 
.7 - 'begin'. rv.\'-v.: . W . ;^-;r ..-j-t.^ » •"^•r:^/ 
8 process ben .>:-UiMlr invt^ is* t^.'i?-. .> - 
9. f; ., ™ port (cd) : -• modua . in. 
10 *** port(qa) : - modus out: / 

11 /* analogous for other process ports */ 

12 var(vq) :- type integer, init 0,^> ; ^ .y 

13 v. var(vco) ■ : r type bit, init \0* 

14 /* same for vqa. .vqd */ 

15 begin. "■*'"•'. 

16 when<cd-'0') : - • •"' v ' : * = *^" ' 7 - : -~ r T 

17 vq :» 0, • .■ ' . 'T- 
IS * /* analogous to guarded command below*/ 

19 when < (cd- ' 1 * and up- ' 1 \ and en- ' 0 ' and cin- 1 0 • 

and rise (cp))) 

20 .-' . call succ(vq,16), - r ~. . 

21 ■■:-.-./• analogous to guarded command below*/ 

22 when <( cd- ' 1 • and up-'O' and en-'O* and cin-'O* 

and rise(cp) ) ) : - 

23 call pred(vq,16), 

24 vco bit ( not ( vqa- up and vqb-up and vqc-up 

and vqd- up and cin-'O')), 

25 * intToBit(vq, [vqa,vqb, vqc, vqd) ) , 

26 if {vco-'O' , 

27 assign(co, force(vco), 

delay ( (cd,co,hl)) , - ! r,*' 1 ** ,'■ 

28 assign (co, force(vco), 

delay( (cd,co,lh>) ) , .. 

29 . • /* analogous for qa . .qd */ .. ' V v. / 

30 end beh.. . _ 

31 . ■ .,■ '• ■ - ,j ; : -- : ••• • • - • 

32 operate (typ) name 'TYP* ,'• comment 'typical 

operating condition'. 

33 ,. .,. .,r.*~-.y, ■ • - ;. -i - - •• ---v- 

34 delay { (Cp, q, lh)) name . • CP_0L_LH * 

prop (typ, 1510) , load (typ, 100) . 

35 constraint ( (up, cp) ):- type setup, name 

' SE_up 1 , setup (typ ,4960) . 

36 * • < 

37 raacro(pred(INT,HODOLO) ) : - - . , ( 

38 MODI is MOD0LO-1, 

39 INT :- if ( 1NT>0, INT- 1, MODI) . 

40 ... " . 
.41 assert ( (up, cp) )r: setup(up,cp) / ; . .i L,:t 
42-. when (cd-M* and en-'O' and rise(cp)), 

43 name •UPjCP*, constraint <( up, cp) ) . 
44 

45 end 'COD42'. . 

Example 1 : Component specification of 4-blt 
r, js • counter -*-••;>••:• , ;.*:». : 



. t i 



1 operate ( typ, typ ) . /* All possible types mapped*/ 

2 operate (mi n, typ) . /*to the type typ*/ < 

3 operate (max, typ) . 

4 act(cd,low) ..... /* Activities required by the*/ 

5 act (up, data) . /*timing checks*/ 

6 act(en,low). 

•7 act(cin,low)". — ^v^'-,- • '.f-.v y?$-. 

8 act(cp, rising) . 

Example 2: MSi data for 4-bit counter required by 
QMD modelling technique [BKLP92] 
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VHDL source code 



1 ENTITY C0D42_g IS 4 -bit UP/DOWN -COUNTER 
With CLEAR, EXPANDABLE 



2 GENERIC ( ...);- 

3 port( ..&?vr£-'^:-:.:.iK->->. • .•; • '• 

4 g_cp : in ,.. . cl_wiogic; .clear T . f .:„ 

5 g_0P:IN, cl_wlogic; -- up/down selec 

6 g_QA:OOT cl_wlogic; counter bit 1 

7 ■• .>;w. r • --■•^ ; * : --"'- ■ 

s ... ■' : *. ■■- ■ 

9 END CUD42_gr" ~ * v ' ; 

10 ' ' ^; - ^'iJrX' ! " 

11 ARCHITECTURE gen OF CUD42_g IS ^ 

12 FU_beh : PROCESS ( g_CD , g_UP , g_EN , glCI N , g_CP j 

13 VARIABLE v_vq : INTEGER: -0; 

14 VARIABLE V_vco ..:„ Cl_logic:-Cl_0; 

15 : . • ' , . , , . 

16 VARIABLE inter : cl_logic_v(0 to 31> ; 

17 BEGIN vi-.;w;.; I- yS\\ ■ ... .' f - r ;r ; . 

18 no_id <- FALSE; • ! 

19 IF (g_CD :- Cl_0) THEN ' ^ v ^ , - 

20 . V_vq":- 0; ' '' ' •• ~ ~ ■ 

21 .-../>'.♦-.-.:•> 

22 ELSIF ( (g_CD cl_l) AND ( (g_UP - cl_l ) AND 

(<g_EN cl_0) AND ((gjCIN - cl_0) 
AND cl_rising(g_CP))))) THEN 

23 "~ v_vq :- cl_if2int( ( (v_vq + 1)' <"" " " " 

16),(v_vq :,4 1),0); ' i> .:m ; = ; ; 
2^ r - ~ * ■ * • . . • . .. H ,. ...... . . . _ . 

25 ELSIF { (9_CD - cl_l) AND ((g_0P - cl_0) AND 
. { ( g_EN, - c 1_;0 ) AND ( ( 9_CIN - cl_0 );>- f 

and cl_rising(g_CP))))) THEN 

2$ v_vq :- cl_if_int( (v_vq > 0),(v_vq~- 

„ ' DV15); -o^^.?..'- 

27 v_vco : - clJt>it((NOT ((v_vqa - g_UP) AND 

"~ — ( ( V_vqb -" g_UP) AND ( (v_vqc - g_DP)"* :' 

. AND ((V_vqd - g_UP) AND (g^ClN - - 

ci^o))))))); : .. M , r - ; 

2B cl_int21o( 1 Ui ; 
:29 -r; d -> v_vq, — i '-^" v " — • H; 

30 . >' ; <s -> inter); v. - 

31 v_vqa :- inter ( 31 ) ; 

32 v_vqb:- Inter (30); ' 

33 v_vqc : - inter { 29 ) ; j * 

34 y.vqd: *- inter ( 28) ; .. r , ... , k - J 

35 IF (v_vco - cl_0) THEN * " »'- r *-*** "V • 

36 g_CO <- cl_f orce ( 0 ) ? " * 

37 ^ del_CO<-4.25E+00 ns; ' > r 

38 ELSE • ,^ . j 

39 g^CO <- cl_force(l); w - t-,- 

40 — r del^CO<-2 . 71E+00 nsr : ! 

41 ' • END IP; ; i.'-; . w.i. vr'itJJ^ififwT f 
!42 



43 END IF; 

44 END PROCESS; 

45 : 

46 END gen; 

Example 3: Generated VHDL code 



6. 



Performance data 
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In order to get first aproximation of the system's perform- 
ance we experimented with standard cell models of: — 

♦ AN2 2-input AND Gate * ^ 

* DFFRS D-flip-flop with Preset & Set - ' ■ ^ \ 

• CUD42 4-bit Up/Down-counter with clear, 
expandable 

The modelling technique developed at Thomson-CSF 
[Ttiom92] requires more method specific information as it 
allows for electrical and physical characteristics (voltage, 
current, temperature, protection class r .) as well as for pin 
numbers. Nevertheless, method specific information is in 
any case very limited in comparison to the common com- 
ponent specification that is to be transformed into the 
ACM, as it is visible from Examples 1 and 2. - 



Table 1 : Static resources 



Module 


- z.v 

kbyte 


lines of .-. 
code 


Method module for mod- 
elling technique devel- 
oped at GMD '•-■[■<::':. 


51 :i ; f 


1600 


Method module for mod- 
elling technique devel- 
oped at Thomsom CSF 


66.6 

L - 


1800 


Preprocessor module 


28.5 


1000 


Server module 


13.0 


550 


User interface-Smalltalk 


75.8 


2000 



Table 2: Dynamic resources 



Component 


AN2 


DFFRS 


CUD42 


Component specifi- 
cation (kbyte) 


1.1 


3.7 


4.9 


Modelling technique developed at GMD 


Method specific 
information (kbyte) 


0.05 

i 


0.12 


0.12 


Generated VHDL 
source code (kbyte) 


7.5 


22.6 


34.9 


Total CPU time used 
for generation (sec) 


3.2 


6.5 


10.4 

■v. ~* 


Modelling technique developed at Thorn som-CSF 


Method specific 
information (kbyte) 


0.22 


031 


0.30 


Generated VHDL - 
source code (kbyte) 


11.6 


27.4 • 


34.9 


Total CPU time used 
for generation (sec) 


4.5 


8.1 


10.0 



7. * ■ < Summary 

A workbench for development of component models has 
been presented. It provides for 

, • generation of , complete behavioural component 
■«,*-■* ^ . models .. T '. - 

• integration of different component modelling tech- 
niques (deep knowledge of both the workbench and 



the modelling technique is required) 

• sharing of specifications using an extendable set of 
. component definition formats (knowledge of the 

internal component representation is required) 

By splitting specifications into two parts, we were able to 
generate complete component models using single specifi- 
cations (the ACM) augmented by information (the MSI) 
specific for each component modelling technique used. 
The programming environment which was used (Quintus- 
Prolog and Objectworks-Smalltalkj has proven to be ade- 
quate for our purposes, particularly robustness, program- 
ming efficiency and runtime performance were highly 
satisfactory. 

We are going to extend the system in the following 
respects: 

• Available preprocessors are tuned for specification 
of standard cells. Modelling rules for complex 
components have to be studied, especially in rela- 
tion to their simulation efficiency; respective 
method and preprocessor modules are to be defined 

• An extension of the client module interface would 
allow stronger coupling of client and server and 
should make possible an improved integration of 
user interface and generator 
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